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Data Dictionary 


Data dictionary is a main method for 
analyzing the data flows and data 
stores of data-oriented systems. 

The data dictionary is a reference work 
of data about data (metadata). 

It collects, coordinates, and confirms 
what a specific data term means to 
different people in the organization. 
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Reasons for Using a Data 
Dictionary 


The data dictionary may be used for the 
following reasons: 

• Provide documentation. 

• Eliminate redundancy. 

• Validate the data flow diagram. 

• Provide a starting point for developing 
screens and reports. 

• To develop the logic for DFD processes. 
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The Repository 


A data repository is a large collection of 
project information. 

• It includes: 

• I nformation about system data. 

• Procedural logic. 

• Screen and report design. 

• Relationships between entries. 

• Project requirements and deliverables. 

• Project management information. 
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Data Dictionary and 
Data Flow Diagram 


Figure 8.1 How data dictionaries relate to data flow diagrams. 


Data Flow Diagram 


Data Flow 

> 


Data Store 


Data Dictionary 






Kendall & Kendall 


© 2005 Pearson Prentice Hail 


8-6 


Data Dictionary Contents 


Data dictionaries contain: 

• Data flow. 

• Data structures. 

• Elements. 

• Data stores. 
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Defining Data Flow 


Each data flow should be defined with 
descriptive information and its 
composite structure or elements. 

Include the following information: 

• ID - identification number. 

• Label, the text that should appear on the 
diagram. 

• A general description of the data flow. 
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Defining Data Flow 
(Continued) 


• The source of the data flow 

•This could be an external entity, a process, or a 
data flow coming from a data store. 

• The destination of the data flow 

• Type of data flow, either: 

• A record entering or leaving a file. 

• Containing a report, form, or screen. 

• Internal - used between processes. 
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Defining Data Flow 
(Continued) 


• The name of the data structure or 
elements 

• The volume per unit time 

•This could be records per day or any other unit 
of time. 

• An area for further comments and 
notations about the data flow 
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Data Flow Example 


Name 

Customer Order 

■ 

Description 

1 

1 

1 

r|i 

fi 

Contains customer order information and is used 
to update the customer master and item files and 
to produce an order record. 

Source 

1 1 

Destination 

in i 

Customer External Entity 
Process 1 , Add Customer Order 


Type Screen 

Data Structure Order Information 

Volume/Time 10/hour 

Comments An order record contains information for one 


1 

HI 

1 

1 ii 11 
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customer order. The order may be received by 
mail, fax, or by telephone. 
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Defining Data Structures 


Data structures are a group of smaller 
structures and elements. 

An algebraic notation is used to 
represent the data structure. 
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Algebraic Notation 


The symbols used are: 

• Equal sign, meaning "consists of". 

• Plus sign, meaning "and". 

• Braces {} meaning repetitive elements, a 
repeating element or group of elements. 

• Brackets [] for an either/or situation. 

•The elements listed inside are mutually 
exclusive. 

• Parentheses () for an optional element. 
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Repeating Groups 


A repeating group may be: 

• A sub-form. 

• A screen or form table. 

• A program table, matrix, or array. 

There may be one repeating element or 
several within the group. 
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Repeating Groups (Continued) 


The repeating group may have: 

• Conditions. 

• A fixed number of repetitions. 

• Upper and lower limits for the number of 
repetitions. 
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Physical and Logical Data 
Structures 


Data structures may be either logical or 
physical. 

Logical data structures indicate the 
composition of the data familiar to the 
user. 
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Physical Data Structures 


Include elements and information 
necessary to implement the system 

Additional physical elements include: 

• Key fields used to locate records. 

• Codes to indicate record status. 

• Codes to identify records when multiple 
record types exist on a single file. 

• A count of repeating group entries. 
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Data Structure Example 


Customer Order = Customer Number + 

Customer Name + 
Address + 

Telephone + 

Catalog Number + 

Order Date + 

{ Order Items } + 
Merchandise Total + 
(Tax) + 

Shipping and Handling + 
Order Total + 

Method of Payment + 
(Credit Card Type) + 
(Credit Card Number) + 
(Expiration Date) 
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Structural Records 


A structure may consist of elements or 
smaller structural records. 

These are a group of fields, such as: 

• Customer Name. 

• Address. 

• Telephone. 

Each of these must be further defined 
until only elements remain. 
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General Structural Records 


• Structural records and elements that are used 
within many different systems should be 
given a non-system-specific name, such as 
street, city, and zip. 

The names do not reflect a functional area. 

This allows the analyst to define them once 
and use in many different applications. 
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Structural Record Example 


Customer Name = First Name + 

(Middle Initial) + 
Last Name 

Address = Street + 

(Apartment) + 
City + 

State + 

Zip + 

(Zip Expansion) + 
(Country) 

Telephone = Area code + 

Local number 
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Defining Elements 


Data elements should be defined with 
descriptive information, length and type 
of data information, validation criteria, 
and default values. 

Each element should be defined once in 
the data dictionary. 
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Defining Elements (Continued) 


Attributes of each element are: 

• Element ID. This is an optional entry that 
allows the analyst to build automated data 
dictionary entries. 

• The name of the element, descriptive and 
unique 

• It should be what the element is commonly 
called in most programs or by the major user of 
the element. 
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Defining Elements (Continued) 


• Aliases, which are synonyms or other 
names for the element 

• These are names used by different users 
within different systems 

• Example, a Customer Number may be 
called a: 

• Receivable Account Number. 

• Client Number. 
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Defining Elements (Continued) 


• A short description of the element 

• Whether the element is base or derived 

•A base element is one that has been initially 
keyed into the system. 

•A derived element is one that is created by a 
process, usually as the result of a calculation or 
some logic. 

• The length of an element 
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Determining Element Length 


What should the element length be? 

• Some elements have standard lengths, 
such as a state abbreviation, zip code, or 
telephone number. 

• For other elements, the length may vary 
and the analyst and user community must 
decide the final length. 
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Determining Element Length 
(Continued) 


• Numeric amount lengths should be 
determined by figuring the largest number 
the amount will contain and then allowing 
room for expansion. 

• Totals should be large enough to 
accommodate the numbers accumulated 
into them. 

• It is often useful to sample historical data 
to determine a suitable length. 
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Determining Element Length 


Element 

Length 

Percent of data that will 
fit within the length 

Last Name 

11 

98% 

First Name 

18 

95% 

Company Name 20 

95% 

Street 

18 

90% 

City 

17 

99% 
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Data Truncation 


If the element is too small, the data will 
be truncated. 

The analyst must decide how this will 
affect the system outputs. 

If a last name is truncated, mail would 
usually still be delivered. 

A truncated email address or Web 
address is not usable. 
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Data Format 


The type of data, either numeric, date, 
alphabetic or alphanumeric or other 
microcomputer formats 

Storage type for numeric data 

• Mainframe: packed, binary, display. 

• Microcomputer (PC) formats. 

• PC formats depend on how the data will be used, 
such as Currency, Number, or Scientific. 
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Personal Computer Formats 


Bit - A value of 1 or 0, a true/false value 

Char, varchar, text - Any alphanumeric character 

Datetime, smalldatetime - Alphanumeric data, several formats 

Decimal, numeric - Numeric data that is accurate to the least significant digit 

Can contain a whole and decimal portion 
Float, real - Floating point values that contain an approximate decimal value 
Int, smallint, tinyint - Only integer (whole digit) data 
Money, smallmoney - Monetary numbers accurate to four decimal places 
Binary, varbinary, image - Binary strings (sound, picture, video) 

Cursor, timestamp, uniqueidentifier - A value that is always unique 

within a database 
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Defining Elements - Format 


Input and output formats should be included, 
using coding symbols: 

• Z - Zero suppress. 

• 9 - Number. 

• X - Character. 

• X(8) - 8 characters. 

• . , - Comma, decimal point, hyphen. 

• These may translate into masks used to 
define database fields. 
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Defining Elements - Validation 


Validation criteria must be defined. 
Elements are either: 

• Discrete, meaning they have fixed values. 

• Discrete elements are verified by checking the 
values within a program. 

•They may search a table of codes. 

• Continuous, with a smooth range of values. 

• Continuous elements are checked that the data 
is within limits or ranges. 
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Defining Elements 


Include any default value the element 
may have 

The default value is displayed on entry 
screens 

Reduces the amount of keying 

• Default values on GUI screens 

•Initially display in drop-down lists 

•Are selected when a group of radio buttons are 
used 


Kendall & Kendall 


© 2005 Pearson Prentice Hail 


8-34 


Defining Elements (Continued) 


An additional comment or remarks area. 

• This might be used to indicate the 
format of the date, special validation 
that is required, the check-digit method 
used, and so on. 
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Data Element Example 


Name 

Alias 

Alias 

Description 


Customer Number 
Client Number 
Receivable Account Number 

Uniquely identifies a customer that has made any business 
transaction within the last five years. 


Length 6 

Input Format 9(6) 

Output Format 9(6) 

Default Value 

Continuous/Discrete Continuous 


Type 

Base or Derived 
Upper Limit 
Lower Limit 
Discrete 
Comments 


Numeric 

Derived 

<999999 

>18 

Value/Meaning 

The customer number must pass a modulus- 11 check-digit test. 
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Defining Data Stores 


• Data stores contain a minimal of all 
base elements as well as many derived 
elements. 

Data stores are created for each 
different data entity; that is, each 
different person, place, or thing being 
stored. 
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Defining Data Stores 
(Continued) 


Data flow base elements are grouped 
together and a data store is created for 
each unique group. 

Since a data flow may only show part of 
the collective data, called the user view, 
you may have to examine many 
different data flow structures to arrive 
at a complete data store description. 
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Data Store Definition 


• The Data Store I D 

The Data Store Name, descriptive and 
unique 

An Alias for the file 
A short description of the data store 

• The file type, either manual or 
computerized 
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Data Store Definition 
(Continued) 


If the file is computerized, the file format 
designates whether the file is a database file 
or the format of a traditional flat file. 

The maximum and average number of 
records on the file 

• The growth per year 

• This helps the analyst to predict the amount of 
disk space required. 
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Data Store Definition 
(Continued) 


The data set name specifies the table or 
file name, if known. 

• In the initial design stages, this may be left 
blank. 

The data structure should use a name 
found in the data dictionary. 
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Data Store Definition - Key 
Fields 


Primary and secondary keys must be 
elements (or a combination of 
elements) found within the data 
structure. 

Example: Customer Master File 

• Customer Number is the primary key, 
which should be unique. 

• The Customer Name, Telephone, and Zip 
Code are secondary keys. 
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Data Store Example - Part 1 


ID 



Name 

Alias 

Description 
File Type 
File Format 
Record Size 
Maximum Records 
Average Records 
Percent Growth/Year 


Customer Master 
Client Master 

Contains a record for each customer 
Computer 
Database 
200 

45.000 

42.000 
6% 
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Data Store Example - Part 2 


Data Set/Table Name Customer 
Copy Member Custmast 


Data Structure 
Primary Key 
Secondary Keys 

Customer Record 
Customer Number 

Customer Name, Telephone, Zip Code 


Comments The Customer Master file records are 

copied to a history file and purged if the customer has not 
purchased an item within the past five years. A customer 
may be retained even if he or she has not made a purchase 
by requesting a catalog. 
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Data Dictionary and Data Flow 
Diagram Levels 


Data dictionary entries vary according 
to the level of the corresponding data 
flow diagram. 

Data dictionaries are created in a top- 
down manner. 

Data dictionary entries may be used to 
validate parent and child data flow 
diagram level balancing. 
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Data Flow Diagram Levels 
(Continued) 


Whole structures, such as the whole 
report or screen, are used on the top 
level of the data flow diagram. 

• Either the context level or diagram zero 

• Data structures are used on 
intermediate-level data flow diagram. 

Elements are used on lower-level data 
flow diagrams. 
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Data Dictionary and 
Data Flow Diagram Levels 


Figure 8.13 Two data flow diagrams and corresponding data dictionary entries for producing an 
employee paycheck. 
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Data Structure 


Employee = Employee Number + 
Record Personal Information + 

Wage Information + 
Current Pay Information + 
Year-to-Date Information 

Timefile = Employee Number + 
Record Employee Name + 

Hours Worked 


Employee = Employee Number + 
Paycheck Employee Name + 
Address + 

Current Pay Amounts + 
Year-to-Date Figures 


Hours 

Worked 


’ ' 


Vtage 

Information 


5.3 


Computer 

Current 

Pay 

Amounts 


Current Pay 
Amounts 


Wage = Rate of Pay + 
Information Number of Dependents 


Current = Gross Pay + 

Pay Federal Withholding + 

Amounts State Withholding + 

Social Security Withholding + 
Net Pay 
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Creating Data Dictionaries 


1. Information from interviews and J AD 
sessions is summarized on Input and 
Output Analysis Forms. 

• This provides a means of summarizing 
system data and how it is used. 

2. Each structure or group of elements 
is analyzed. 
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Creating Data Dictionaries 
(Continued) 


3. Each element should be analyzed by 
asking the following questions: 

• Are there many of the field? 

• If the answer is yes, indicate that the field is a 
repeating field using the { } symbols. 

• Is the element mutually exclusive of 
another element? 

• If the answer is yes, surround the two fields 
with the [ | ] symbols. 
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Creating Data Dictionaries 
(Continued) 


• Is the field an optional entry or optionally 
printed or displayed? 

• If so, surround the field with parenthesis ( ). 

4. All data entered into the system must 
be stored. 

• Create one database table or file for each 
different type of data that must be stored. 

• Add a key field that is unique to each 
table. 
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Determining Data Store 
Contents 


Data stores may be determined by 
analyzing data flows. 

Each data store should consist of 
elements on the data flows that are 
logically related, meaning they describe 
the same entity. 
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Maintaining the Data 
Dictionary 


To have maximum power, the data 
dictionary should be tied into other 
programs in the system. 

When an item is updated or deleted 
from the data dictionary it is 
automatically updated or deleted from 
the database. 
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Using the Data Dictionary 


Data dictionaries may be used to: 

• Create reports, screens, and forms. 

• Generate computer program source code. 

• Analyze the system design for completion 
and to detect design flaws. 
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Creating Reports, Screens, 
Forms 


To create screens, reports, and forms: 

• Use the element definitions to create fields. 

• Arrange the fields in an aesthetically 
pleasing screen, form, or report, using 
design guidelines and common sense. 

• Repeating groups become columns. 

• Structural records are grouped together on 
the screen, report, or form. 
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Data Dictionary Analysis 


The data dictionary may be used in 
conjunction with the data flow diagram 
to analyze the design, detecting flaws 
and areas that need clarification. 
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Data Dictionary Analysis 
(Continued) 


Some considerations for analysis are: 

• All base elements on an output data flow 
must be present on an input data flow to 
the process producing the output. 

• Base elements are keyed and should never 
be created by a process. 
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Data Dictionary Analysis 
(Continued) 


• A derived element should be output from 
at least one process that it is not input 
into. 

• The elements that are present on a data 
flow into or coming from a data store must 
be contained within the data store. 


Kendall & Kendall 


© 2005 Pearson Prentice Hail 


8-57 


Extensible Markup Language 
(XML) 


XML is used to exchange data between 
businesses. 

An XML document may be transformed 
into different formats. 

The transformation may limit the data 
seen by a user. 

XML may be sorted, filtered, and 
translated. 
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Using Data Dictionaries to 
Create XML 


The data dictionary is an ideal starting 
point for developing XML. 

Data names are stored within tags, a 
less than and greater than symbol. 

<customer> or <lastName> 

The data dictionary is organized using 
structures, which are included in XML. 
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XML Document Type Definition 
(DTD) 


• A DTD is used to ensure that the XML 
data conforms to the order and type of 
data specified in the DTD. 

DTD's may be created using the data 
dictionary. 
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